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REMARKS 

This amendment is responsive to the Final Office Action dated March 11, 2009. 
Applicant has amended claims 7-10 and 12-13 and added new claims 22-28. Claims 1-6, 11, 
and 14-21 were previously cancelled. Claims 7—10, 12—13, and 22—28 are pending upon 
entrance of this Amendment. 

Claim Rejection Under 35 U.S.C. g 101 

The Final Office Action rejected claims 7-10, 12 and 13 under 35 U.S.C. § 101, asserting 
that the claimed invention is directed to non-statutory subject matter. Applicant respectfully 
disagrees, but nevertheless to expedite prosecution, Applicant has amended claim 7 to require 
that each of the elements of claim 7 are performed "by a computing device." The algorithm that 
transforms a general purpose computing device to a particular computing device is the algori thm 
required by the method of amended claim 7. That is, the elements of claim 7 transform an 
otherwise general purpose computing device to a particular computing device when the 
computing device executes each of the elements required by amended claim 7. In particular, 
amended claim 7 requires: 

executing, by a computing device , an enterprise planning session in accordance 
with an enterprise planning model, wherein the enterprise planning model defines 
hierarchically arranged nodes associated with business logic software modules and 
enterprise contributors, wherein executing_the enterprise planning session comprises: 

receiving , by the computing device, contribution data provided by the enterprise 
contributors; and 

automating , by the computing device, reconciliation of the contribution data 
across an enterprise that corresponds to the enterprise planning model by automatically 
aggregating the contribution data as the contribution data is received, wherein the 
enterprise planning model comprises a financial model; 

checking-out , by the computing device, an individual one of the nodes of the 
model for editing during execution of the enterprise planning session in accordance with 
the enterprise planning model; and 

modifying , by the computing device, the checked-out individual one of the 
nodes of the model without preventing execution of the enterprise planning session for 
the nodes of the enterprise planning model that are not checked-out. 
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In this manner, claim 7 as amended literally requires that a computing device performs 
each act of the method recited therein. When a general purpose computing device performs this 
method, the general purpose computing device becomes a particular computing device by the 
very nature of performing each of these acts. For at least these reasons, amended claim 7 is 
statutory and patentable over 35 U.S.C. § 101. Dependent claims 8-10, 12, and 13 incorporate 
these requirements, therefore the dependent claims are likewise statutory. Applicant therefore 
respectfully requests withdrawal of this rejection. 

Claim Rejection Under 35 U.S.C. $ 112 

35 U.S.C. $112. IT 1 

The Final Office Action rejected claims 7-10, 12 and 13 under 35 U.S.C. § 1 12, first 
paragraph, as failing to comply with the written description requirement. Applicant respectfully 
disagrees. 35 U.S.C. § 1 12, If 1 requires: 

The specification shall contain a written description of the invention, and of the 
manner and process of making and using it, in such full, clear, concise, and exact 
terms as to enable any person skilled in the art to which it pertains, or with which 
it is most nearly connected, to make and use the same, and shall set forth the best 
mode contemplated by the inventor of carrying out his invention. 
Applicant previously cited one example of the specification that discloses reconciliation, 
i.e., 51-52. This is merely one example portion of Applicant's specification regarding 
reconciliation. Another example portion of Applicant's specification that discloses 
reconciliation is *\ 3 1 , reproduced below (with emphases added): 

[031] During the reconciliation phase, enterprise planning system 3 automates 
the reconciliation of the forecast data with the corporate targets provided by 
analysts 8. In particular, enterprise planning system 3 operates in accordance with 
the defined model to provide a hierarchical planning process having multiple 
reconciliation levels. As each of contributors 6 provides his or her contribution 
data, enterprise planning system 3 automatically aggregates the contribution 
data across enterprise 4 in real-time , and provides access to the aggregated data 
to reviewers 9 associated with higher levels of enterprise 4. In particular, upon 
receiving contribution data from contributors 6, enterprise planning system 3 
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identifies all higher levels of the organizational model affected by the newly 
received contribution data, and calculates new aggregate totals at each level 
in real-time . 

Applicant's specification at | 32 further discloses details regarding reconciliation, as 
reproduced below (with emphases added): 

[032] Consequently, reviewers 9 view aggregated data across enterprise 4 in 
real-time during the enterprise planning session. At each level, enterprise 
planning system 3 ensures that reviewers 9, as defined by the nodes of the 
enterprise model reconcile the target data with the forecast data . Each 
reviewer 9 may, for example, reject or accept the contribution data in view of 
corporate targets provided by analysts 8. This process continues until the 
contribution data is ultimately approved by the highest level of the organizational 
hierarchy, thereby ensuring that the contribution data from contributors 6 
reconciles with corporate targets provided by analysts 8 . 

In this manner, Applicant's specification describes an enterprise planning system that 
"may improve the accuracy and predictability of enterprise planning by enabling organizations to 
reconcile corporate models and organizational targets with detailed forecasts." Specification, 
H 33. Moreover, as shown above, Applicant's specification describes the manner in which a 
computing device executing the method of claim 7 participates in the reconciliation phase, i.e., a 
computing device that "automates reconciliation of contribution data," as required by amended 
claim 7. 

To further provide evidence that Applicant's Specification discloses the requirements of 
amended claim 7 with respect to reconciliation, Applicant respectfully directs the Examiner's 
attention to FIGS. 5-8 and the corresponding portions of the specification, i.e., fflf 70-85. FIGS. 
5 and 6 depict an example organization of a transactional data area in accordance with a 
hierarchy defined by an enterprise planning model. See also Specification, HI 21, 70. 
Applicant's Specification, at 71-72, describes the model for hierarchy 70 depicted in FIG. 5. 
FIG. 6 illustrates the manner in which contribution data from each outlet and each region may be 
stored in a transactional data area. Specification, | 60. Applicant's Specification further 
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discloses that, in this manner, a planning system or computing device may aggregate data for 
each node in the hierarchy. Specification, H 74. As Applicant's Specification describes, 
reconciliation includes the aggregation of contribution data. 

FIG. 7 illustrates a method for performing a planning session. As described in 
Applicant's Specification, a planning session includes three stages: (1) a modeling stage, (2) a 
contribution stage, and (3) a reconciliation stage. See, e.g., Applicant's Specification, ^ 8. FIG. 
7, reproduced below, illustrates steps for each stage: 

START 

RECEIVE INPUT DEFINING A PLANNING 80 
MODEL HAVING MULTIPLE DIMENSIONS 

RECEIVE INPUT DEFINING AN ; 82 

| ENTERPRISE HIERARCHY 
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HIERARCHY AND INITIALIZE ENTERPRISE 1 84 
_ DATA 

RECEIVE TARGET DATA FROM ANALYSTS 
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REAL-TIME 
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TARGET DATA 

[ ■ ' " OA 

PUBLISHING THE CONTRIBUTION DATA 
GENERATE ANALYTICAL REPORTS 96 

N ° RECONCILED? 98 
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END 

In the example of FIG. 7, steps 88-98 generally correspond to the reconciliation stage. 
This is evident from Applicant's specification, | 80, which states, "Enterprise planning system 3 
repeats the reconciliation process until the contribution data and aggregate totals are accepted by 
the high-level reviewer of the organizational hierarchy (98)." As is evident from FIG. 7, the 
method prescribes determining whether the data has been reconciled (98), and if not, steps 88-98 
are repeated. Accordingly, each of steps 88-98 in FIG. 7 correspond to an example method for 
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performing reconciliation by a computing device. FIG. 8 provides details regarding aggregation 
of contribution data across an enterprise. See, e.g., If 81. As disclosed throughout the 
Specification, aggregation of contribution data corresponds to one aspect of the reconciliation 
phase. See, e.g., | 31. 

For at least these reasons, the Specification satisfies the requirements of 35 U.S.C. § 1 12, 
U 1 with respect to amended claim 7. Dependent claims 8-10, 12, and 13 incorporate the 
requirements of amended claim 7, therefore the Specification satisfies the requirements of 35 
U.S.C. § 1 12, T| 1 with respect to the dependent claims, insofar as those claims incorporate the 
requirements of independent claim 7 as amended. Moreover, the dependent claims include 
additional requirements that satisfy the requirements of 35 U.S.C. § 1 12, as respectively 
amended. 

As a preliminary matter, Applicant notes the amendments to claims 10, 12, and 13 
removing the word "reconciling" and instead reciting "wherein automating reconciliation 
comprises ..." Therefore, the rejection asserting that "the scope of 'reconciling' is unclear" is 
rendered moot. Moreover, the claims themselves further define the scope of the requirement 
"automating reconciliation." 

Amended claim 1 0 requires receiving and processing the contribution data from the 
enterprise contributors associated with the nodes of the model during the execution of the 
enterprise planning session and prior to the check-out of the individual one of the nodes, and 
reconciling the contribution data that was received prior to the check-out of the individual one of 
the nodes with the updated model information when the checked-out individual one of the nodes 
is subsequently checked-in during the execution of the enterprise planning session. Amended 
claim 10 further requires "wherein automating reconciliation comprises updating the data of the 
checked-out one of the nodes with the contribution data that was received prior to the check-out 
of the individual one of the nodes in accordance with the updated model information when the 
checked-out individual one of the nodes is subsequently checked-in during the execution of the 
enterprise planning session." FIGS. 7 and 8, discussed above, and the corresponding discussion 
in the Specification, support this requirement of claim 10. 

The Final Office Action stated, with respect to claim 10, that "[fjhe scope of 'reconciling' 
is not clear." As amended, claim 10 requires "wherein automating reconciliation," rather than 
"reconciling," as previously presented. The requirements of amended claim 10 further define the 
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requirement of "automating reconciliation." This amendment is consistent with Applicant's 
specification, e.g., at fU 51, 52, 79, 82, and 85. Therefore, the Specification supports the 
requirements of amended claim 1 0. 

The Final Office Action also rejected claim 12, asserting that the scope of claim 12 is 
unclear. Amended claim 12 requires "wherein automating reconciliation comprises defining 
reconciliation jobs for execution by an application server to prompt a reviewer to reconcile the 
previously received contribution data with the updated model information for the checked-in 
individual one of the nodes." This amendment is consistent with Applicant's specification, e.g., 
at 38-40, 47, 48, 52, 53, 93, and 105. For example, Applicant's specification at ^ 39 states, 
"[j]ob data 42C defines administration jobs for execution application servers 26, and 
configuration (CONFIG) data 42D stores basic configuration data for enterprise planning system 
3." Therefore, the Specification supports the requirements of amended claim 12. 

The Final Office Action also rejected claim 13, asserting that the scope of claim 13 is 
unclear. Amended claim 13 requires "wherein automating reconciliation comprises defining 
reconciliation jobs for execution by remote computers of the enterprise contributors to prompt 
the enterprise contributors to reconcile the previously received contribution data with the updated 
model information for the checked-in individual one of the nodes." This amendment is 
consistent with Applicant's specification, e.g., at fflf 38^10, 47, 48, 52, 53, 93, and 105. For 
example, Applicant's specification states, "authentication servers 44 may 'push' reconciliation 
jobs to the local computing devices." Specification, | 52. Therefore, the Specification supports 
the requirements of amended claim 13. 

For at least these reasons, claims 7-10, 12, and 13 comply with 35 U.S.C. § 1 12, first 
paragraph. Applicant therefore respectfully requests withdrawal of this rejection. 

35 U.S.C. $112. 112 

In the Final Office Action, the Examiner rejected claims 7-10, 12 and 13 under 35 U.S.C. 
112, second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. Applicant has amended claim 
7 for purpose of clarification. Amended claim 7 requires automating, by the computing device, 
reconciliation of the contribution data across an enterprise that corresponds to the enterprise 
planning model by automatically aggregating the contribution data as the contribution data 
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is received . As discussed at great length above, Applicant's specification supports this 
amendment, e.g., at f 3 1 . Applicant submits that amended claim 7 particularly points out and 
distinctly claims the subject matter, as required by 35 U.S.C. § 1 12, second paragraph. 
Dependent claims 8-10, 12, and 13 incorporate the requirements of amended claim 7, therefore 
the dependent claims likewise comply with the requirements of 35 U.S.C. § 1 12, second 
paragraph. Applicant therefore respectfully requests withdrawal of this rejection. 

Claim Rejection Under 35 U.S.C. § 103 

The Final Office Action rejected claims 7-10, 12 and 13 under 35 U.S.C. § 103(a) as 
being unpatentable over Elkin et al. (U.S. Patent Publication No. 2007/0179828, hereinafter 
"Elkin") in view of Examiner's Official Notice (citing, e.g., Petra Heinl et al., "A 
Comprehensive Approach to Flexibility in Workflow Management Systems," (hereinafter, 
"Heinl"), and J. J. Halliday et al., "Flexible Workflow Management in the OPENflow System," 
(hereinafter, "Halliday"). Applicant respectfully traverses the rejection to the extent it may be 
considered applicable to the claims as amended. The applied references fail to disclose or 
suggest the invention(s) defined by Applicant's claims, and provide no teaching that would have 
suggested the desirability of modification to arrive at the claimed invention(s). 

Amended claim 7, for example, requires executing, by a computing device , an enterprise 
planning session in accordance with an enterprise planning model, wherein the enterprise 
planning model defines hierarchically arranged nodes associated with business logic software 
modules and enterprise contributors, checking-out, by the computing device, an individual one of 
the nodes of the model for editing during execution of the enterprise planning session in 
accordance with the enterprise planning model, and modifying, by the computing device, the 
checked-out individual one of the nodes of the model without preventing execution of the 
enterprise planning session for the nodes of the enterprise planning model that are not checked- 
out. 

The Final Office Action cited Elkin in view of the Examiner's Official Notice as 
disclosing the requirements of claim 7. However, contrary to the assertions in the Final Office 
Action, Elkin fails to disclose or suggest, for example, executing an enterprise planning session 
in accordance with an enterprise planning model, wherein the enterprise planning model defines 
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hierarchically arranged nodes associated with business logic software modules and enterprise 
contributors , as required by amended claim 7. 

Elkin describes a workflow process, in which a workflow processing model describes 
each task to be performed to accomplish a business goal. See, e.g., Elkin, 13-14. Elkin 
specifically teaches that a workflow processing model includes a plurality of business tasks, 
"which is a unit of work that is to be accomplished by an individual or an existing business 
program." Elkin, ][ 14. Elkin describes the business tasks of a workflow process with respect to 
FIG. 3 therein. See, e.g., Elkin, FIG. 3; fflf 50-53, 128-129. Claim 7, on the other hand, is 
directed to execution of an enterprise planning session according to an enterprise planning 
model. Claim 7 specifically requires that the enterprise planning model defines hierarchically 
arranged nodes associated with business logic software modules and enterprise contributors. 
Elkin fails to disclose or suggest that the workflow process module defines hierarchically 
arranged nodes associated with business logic software modules and enterprise contributors. 

Applicant's FIG. 5 (reproduced below) provides an example of an enterprise planning 
model required by amended claim 7: 
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Elkin fails to disclose or suggest an enterprise planning model that defines hierarchically 
arranged nodes associated with business logic software modules and enterprise contributors, as 
required by amended claim 7. The references cited in support of the Official Notice also fail to 
disclose or suggest this requirement of claim 7, as discussed in greater detail below. 
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Moreover, Elkin fails to disclose or suggest receiving contribution data provided by 
enterprise contributors and automating reconciliation of the contribution data across an enterprise 
that corresponds to the enterprise planning model by automatically aggregating the contribution 
data as the contribution data is received, as required by amended claim 7. As further clarified by 
Applicant's specification, contribution data may include "detailed financial forecasts, revenue 
forecasts, order forecasts, inventory forecasts, estimated resource requirements, and the like." 
Applicant's specification, ^ 30. Elkin fails to disclose or suggest receiving contribution data 
from enterprise contributors. Elkin is instead directed to workflow processing, which stands in 
stark contrast to an enterprise planning session. Workflow processing, as described by Elkin, 
defines a path beginning with receiving an order and ending with providing the ordered 
item/product/service to the customer. See, e.g., Elkin, Abstract. In particular, Elkin is directed 
to creating workflow models. Elkin has nothing to do with an enterprise planning session, which 
(in accordance with Applicant's specification) relates to reconciling top-down requirements with 
bottom-up forecasts. See, e.g., Applicant's specification, \ 4. 

Not only does Elkin fail to disclose or suggest receiving contribution data, Elkin also fails 
to disclose or suggest automating reconciliation of the contribution data by automatically 
aggregating the contribution data as the contribution data is received, as required by amended 
claim 7. Because Elkin fails to disclose or suggest receiving contribution data, Elkin necessarily 
fails to disclose or suggest automatically aggregating the received contribution data. To the 
extent that Elkin discloses receiving data at all, Elkin fails to disclose or suggest automatically 
aggregating contribution data as required by amended claim 7, i.e., in the context of claim 7. 

The references cited in support of the Official Notice fail to overcome the deficiencies of 
Elkin with respect to amended claim 7. Heinl and Halliday, specifically cited by the Final Office 
Action, each also relate to workflow management, not an enterprise planning session. Heinl. p. 
79, Abstract; Halliday, Abstract. Heinl and Halliday both fail to disclose or suggest an enterprise 
planning model that defines hierarchically arranged nodes associated with business logic 
software modules and enterprise contributors. Heinl instead describes a workflow management 
application that supports a business workflow. Heinl, p. 79, col. 2. Heinl is not directed to 
executing an enterprise planning session in accordance with an enterprise planning model that 
defines hierarchically arranged nodes associated with business logic software modules and 
enterprise contributors. Halliday likewise discloses a workflow and fails to disclose or 
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suggestexecuting an enterprise planning session in accordance with an enterprise planning model 
that defines hierarchically arranged nodes associated with business logic software modules and 
enterprise contributors. See, e.g., Halliday, p. 1. 

With respect to the Official Notice, the Examiner asserted that it was old and well known 
to "modify individual nodes of a model," "modify the nodes of the model without preventing 
execution of the session for the nodes that are not checked out," and "check out individual 
nodes." The Examiner cited a variety of references to support the Official Notice. However, the 
references do not support the Official Notice, and the Official Notice, in view of Elkin, fails to 
disclose or suggest the requirements of amended claim 7. 

Amended claim 7 requires an enterprise planning model that defines hierarchically 
arranged nodes associated with business logic software modules and enterprise contributors. 
With respect to the enterprise planning model, amended claim 7 requires checking-out an 
individual one of the nodes of the model for editing during execution of the enterprise planning 
session in accordance with the enterprise planning model and modifying the checked-out of the 
model without preventing execution of the enterprise planning session for the nodes of the 
enterprise planning model that are not checked-out. 

To the extent that Heinl may disclose changing a workflow management application 
during runtime (Heinl, p. 80, col. 1), Heinl fails to disclose or suggest modifying nodes of an 
enterprise planning model without preventing execution of an enterprise planning session for 
the nodes that are not checked out. As discussed above, neither Elkin nor Heinl discloses 
executing an enterprise planning in accordance with an enterprise planning model, as required by 
amended claim 7. Therefore, the nodes disclosed by Heinl do not correspond to nodes of an 
enterprise planning model, i.e., hierarchically arranged nodes associated with business logic 
software modules and enterprise contributors. Accordingly, Heinl fails to disclose or suggest 
how one of ordinary skill in the art could apply the techniques of changing a workflow 
management application in real time to the enterprise planning model required by amended claim 
7, or how to modify Elkin to achieve the requirements of amended claim 7. 

To the extent that Halliday may disclose flexibility of a workflow management process 
(Halliday, Abstract and p. 1), Halliday also fails to disclose or suggest modifying nodes of an 
enterprise planning model without preventing execution of an enterprise planning session for 
the nodes that are not checked out. Halliday specifically teaches modifying a workflow process 
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"to include one or more execution paths." Halliday, p. 1,^3. Adding execution paths to a 
workflow model is not checking out a node, from hierarchically arranged nodes associated v/ith 
business logic software modules and enterprise contributors, for editing and modifying the 
checked-out node without preventing execution of the enterprise planning session for the nodes 
of the enterprise planning model that are not checked-out, as required by amended claim 7. 
Accordingly, Halliday also fails to disclose or suggest the requirements of amended claim 7, 
even in view of Elkin. 

The other documents cited in support of the Official Notice also involve workflow 
models, not enterprise planning models. To date, the Examiner has not cited any references that 
support the Official Notice taken that it is well known to check out an individual one of 
hierarchically arranged nodes, associated with business logic software modules and enterprise 
contributors, of an enterprise planning model for editing during execution of an enterprise 
planning session in accordance with the enterprise planning model, and modifying the checked- 
out individual one of the nodes of the model without preventing execution of the enterprise 
planning session for the nodes of the enterprise planning model that are not checked-out. 
Instead, the Final Office Action relied on an entirely different model (a workflow model) that is 
unrelated to an enterprise planning model. In particular, none of the cited references, alone or in 
combination, disclose or suggest an enterprise planning model that defines hierarchically 
arranged nodes associated with business logic software modules and enterprise contributors. 

Accordingly, amended claim 7 is patentable over the applied prior art. Dependent claims 
8, 9, 10, 12, and 13 incorporate the requirements of amended claim 7, therefore the dependent 
claims are likewise patentable. Moreover, the dependent claims include a number of 
requirements likewise not disclosed or suggested by the applied prior art. 

For example, amended claim 12 requires that automating reconciliation comprises 
defining reconciliation jobs for execution by an application server to prompt a reviewer to 
reconcile the previously received contribution data with the updated model information for the 
checked-in individual one of the nodes, wherein the application server is communicatively 
coupled to the computing device. The Final Office Action didn't apply any of the references to 
claim 12 as previously presented, instead reasserting the § 1 12 rejection. Applicant respectfully 
submits that amended claim 12 overcomes the rejection based on § 1 12. The Final Office Action 
asserted that the scope of "reconciling" is unclear. Applicant respectfully notes that, as the 
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elements of amended claim 12 further define the scope of "automating reconciliation," the scope 
of "automating reconciliation" is made clear by the elements of dependent claim 12. That is, the 
refinements described by the dependent claim further define the scope of the requirement of the 
independent claim being limited in-and-of themselves. Accordingly, Applicant respectfully 
submits that amended claim 12 is patentable under 35 U.S.C. §§ 103 and 112. 

For at least these reasons, the Final Office Action has failed to establish a prima facie 
case for non-patentability of Applicant's claims 7-10 and 12-13 under 35 U.S.C. § 103(a). 
Applicant therefore respectfully requests withdrawal of this rejection. 

New Claims 

Applicant has added claims 22-28 to the pending application. The applied references fail 
to disclose or suggest the invention(s) defined by Applicant's new claims, and provide no 
teaching that would have suggested the desirability of modification to arrive at the claimed 
invention(s). Claims 22-23 depend from independent claim 7, and thus are patentable for at 
least the reasons discussed above. Independent claims 24 and 28 recite subject matter similar to 
amended claim 7, therefore similar remarks apply with respect to claims 24 and 28 as were 
presented with respect to claim 7 in the remarks regarding rejections based on § 103. Claim s 25- 
27 depend from independent claim 24 and thus are patentable by virtue of claim 24 being 
patentable. No new matter has been added by the new claims. 
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CONCLUSION 



All claims in this application are in condition for allowance. Applicant does not 
acquiesce as to any assertion in the Office Action with respect to the prior art or to Applicant's 
claims. Applicant's silence with respect to any assertion in the Office Action should not be 
interpreted as Applicant's acquiescence thereto. Applicant reserves the right to comment further 
with respect to the cited art and/or any pending claim in a future Amendment, Response, or on 
appeal. Applicant respectfully requests reconsideration and prompt allowance of all pending 
claims. 

Please charge any additional fees or credit any overpayment to deposit account number 
50-1778. The Examiner is invited to telephone the below-signed attorney to discuss this 
application. 



SHUMAKER & SIEFFERT, P.A. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8358 
Facsimile: 651.735.1102 



Date: June 11,2009 




Name: Raymond R. Berdie 
Reg. No.: 50,769 
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